先記住：先抓錯金額、錯權限、資料消失與重複提交。
需要深入時：再畫狀態與事件表。

為什麼只是多點兩下就壞了？

優惠券單次送出測試通過了。使用者先輸入 A，立刻又改成 B。
B 的結果先回來，畫面顯示九折；幾秒後 A 的舊結果抵達，又把總額改回去。

每一支 API 都可能正常，畫面卻是錯的。
確實，前端不是依序播放的簡報，而是一個會同時接收輸入、網路回應和時間事件的系統。

隱性需求常藏在三個地方

第一個是狀態
除了成功與失敗，還有尚未載入、載入中、資料已過期，以及結果不明。
這些狀態會影響使用者能做什麼，也影響訊息該怎麼說。

第二個是邊界
空字串、0 元、最大數量、剛好到期、商品突然下架，都是規則最容易暴露模糊的地方。
例如金額0 元可能合法，不能因為它是假值就改用預設金額。

第三個是事件順序
回應順序不保證等於請求順序；使用者可能離開頁面，也可能在另一個分頁修改購物車。

幫畫面畫一張狀態小抄

在這個教學案例裡，優惠驗證可以先分成：

• idle
• validating
• valid
• invalid
• unknown

unknown 表示目前拿不到可信結果，不等於優惠券無效。

每次送出都記住本次的代碼與購物車版本。
回應抵達時，比對是否仍屬於目前操作；不屬於就不提交到畫面。
取消請求可以節省資源，但不能單靠取消證明伺服器沒有執行，所以仍要守住回應套用條件。

如果畫面允許使用者在驗證中繼續改資料，就得設計這個檢查。
如果產品選擇短暫鎖住修改，也要處理逾時解鎖與可用性。
兩種都是取捨，沒有免費的捷徑。

錯誤要接得回流程

「發生錯誤」對工程師可能夠用，對使用者卻不知道下一步。
券已過期時可換代碼；權限失效時可能需要重新登入；報價逾時時可保留草稿並重新取得結果。

更重要的是：錯誤訊息不要假裝知道未知的事情。
建立訂單逾時，只能說目前未確認結果，不能直接說訂單一定建立失敗。
後續要透過已確認的查詢或冪等機制恢復，這需要後端協作。

可以交給 AI 的 Prompt

請替優惠券驗證列出狀態與事件表。情境包含 A 請求晚於 B 回覆、驗證中改商品數量、空白代碼、合法0 元、權限失效、離開頁面和逾時。每列寫出目前狀態、事件、允許轉移、保留資料與使用者下一步。請區分明確失敗與結果不明，不能把所有錯誤轉成空資料。

它用到的是狀態分析與不變條件：任何時刻，畫面上的報價都必須對應目前的購物車。
這句話比「補一下 race condition」更容易驗證。

今日練習與筆記

替一個請求安排兩種回應順序：先發先到、先發後到。
手動寫出每一步畫面應該顯示什麼。
如果答案會隨順序錯亂，就抓到了值得補的邊界。

不用把所有錯誤都預想完，先抓最昂貴的錯誤：錯金額、錯權限、草稿消失與重複提交。
明天再開始繼續把這些工作放進估時。